Security systems are commonly used to prevent theft of vehicles or of vehicle contents, deter removal of vehicle components, for example, wheels and tires, discourage tampering and vandalism, and to enhance security of vehicle occupants. A typical security system includes a variety of sensors. The sensors may be connected essentially in parallel, so that the events detected by the sensors generate alarms, and the individual events are not distinguishable by either the security system or the end user of the security system. (An “event” is typically a security violation, such as unauthorized opening of a door, detection of breaking glass, or trunk opening; the word “event” also encompasses other incidents related to operation of the security system and occurrences in the environment monitored by the security system, such as self-diagnostic problem reporting.) More commonly, sensors are connected individually or in groups, also known as protection zones. Each security violation event can then be associated with a particular zone. Typical protection zones include door sensors protecting the passenger compartment, trunk opening sensor, hood opening sensor, motion detector, tilt sensor, glass break sensor, and proximity sensors.
The security system sensors report events to a system controller. The controller can be a rather sophisticated programmable device capable of performing many tasks, such as self diagnostics. See, for example, commonly-assigned U.S. Pat. No. 4,887,064 to Drori et al., which is hereby incorporated by reference in its entirety. The controller can include or be coupled to an indicator light, for example, a light emitting diode (LED). Using the indicator light, the controller can generate a sequence of light flashes to communicate information to the user of the security system. The information flashed off to the user in this manner can include data regarding events, for example, violations that occurred after the system was armed, and self-diagnostic details, such as security system component failures, and low voltage of the vehicle battery.
In general, flashing sequences convey information to the user by varying the number of flashes, the lengths of the flashes, and the lengths of the intervals between consecutive flashes. The higher the number of reportable events, the longer and more complicated the flashing sequences become. To interpret a specific flashing sequence, the user may need to refer to a manual provided with the security system. Because this is rather inconvenient and impractical, it would be desirable to provide a way for interpreting flashing sequences without recourse to the manual or to another source that may not be readily available to the user of the security system. It would also be desirable to automate interpretation of the flashing sequences, so that the user of a legacy security system would not need to become familiar with the various codes output by the system, and would not need to memorize the codes. Furthermore, automating the process would avoid errors that can be made in interpreting the flashing sequences.
A security system indicator light is generally installed in a location where it is visible both from inside and outside of the vehicle. It is visible from the outside to deter would-be thieves and vandals. It is visible from the inside so that the security system user can read the flashing sequences and verify arming and disarming of the system. The indicator light is thus typically installed in an open location, and can be difficult to observe in daylight. Because indicator light stays ON or flashes when the security system is armed, it can be a major contributor to the total electrical load on the vehicle's battery. The average current through the indicator light is thus kept relatively low in many security system designs, making the light less bright. This aggravates the daylight visibility problem. It would thus be desirable to decrease reliance on the visibility of the indicator light when conveying the event information to the security system user.
A need thus exists to provide a way for users to interpret conveniently the event reporting flashing sequences of security systems. Another need exists for automating the process of interpreting the event reporting flashing sequences. A further need exists to help security system users to receive event information without relying on the visibility of the security system indicator light.